为什么要给通信分组？
想象几张卡互相送数据：数据的目的地已经决定，我们只安排谁先发、同时发多少。先看一个简单办法怎样工作，再亲手制造拥挤，让每一步设计都有来由。
前五步是教学模型 最后一步对应 Ascend MoonEP 64P 源码
金色：源 rank；蓝色：本轮允许访问的 16 个目标。源 rank 同时为目标时保留金色。
带走的是一种思路
从“让所有发送方尽快发”转向“接收资源能承受多少，就允许多少进入”。先限制同时竞争，再让各组错开目的地；快慢不一致时，由接收方决定下一批能否进入。
这个设计主要重排并发与时机。它没有消除需要搬运的数据，也没有凭空增加链路带宽。若现有网络调度已经很好、并发资源足够，额外分组和同步可能只增加等待。
教学模型为什么能解释动机，却不能证明加速？
图中的容量是人为设置的“同时服务发送方数”，线代表这一阶段提出的发送请求，红色条表示超出容量的请求数；它不是时间、字节数、真实丢包或测得的吞吐。八个发送方与八个接收方是同一组卡的两个角色视图，每个发送方假设对每个目的地都有一个等量任务；自访问也为简化计入教学请求。
直接发送共提出 64 个任务。错峰每轮提出 16 个任务，四轮仍是 64 个。容量为 2 时，理想服务下两种方案都需要至少四个服务时段；分组的潜在收益来自真实系统中的竞争、控制开销或拥塞成本，不来自这套任务计数。这里只重建合理设计推导，没有作者口述的决策历史。
小模型用 8 张卡、每组 2 张来缩小问题；实际源码在 8P 会使用一个组，因此这不是 8P kernel 行为复现。进入第六步后才切换到真正的 64P 映射。
为什么恰好 16 个？为什么跨两个 half 取 8+8？
固定源码将 token 组宽上限设为 16；64P 用 16 个 token AIV，每个负责当前目标组中的一个 peer，另 16 个 AIV 处理路由 weight。组员由两个 half 各取 8 个对应位置组成。源码足以确认这项选择，但通用限流推导不足以证明“16 最优”或“8+8 必然优于连续 16 个”。这些还需要真实 rank 到链路的映射、不同组宽和编号方式的对照实验。
每轮的 group 配对是一个置换；组内仍允许 16 个源访问 16 个目标。允许访问不意味着一定发送：实际 token 路由命中才产生 payload，自访问用本地复制。64P 的局部 AIV barrier 加上 peer completion/credit 形成推进约束；页面的统一轮次用于读图，不代表每轮调用全局 barrier。
回到证据：固定版本与代码位置
研究对象为 Ascend 移植版，固定提交 b67c6840f57524724293169404403b8b0880c5e7。这与 MoonshotAI 原版的动态冗余 expert 负载均衡属于不同层次。
- 组宽与 128P 专用分支：64P 继续走 Legacy 路径。
- 目的组、入向 peer 和下一轮 credit peer：组间循环平移及逆变换。
- completion、局部同步、credit、quiet：等待入向完成，再许可下一入向 peer。
- 实际发送路径：筛选路由命中、复制或发送，再处理完成协议。
正文和交互可离线使用；这些来源链接在需要核查时联网打开。